Среди возможностей решения для создания отказоустойчивых хранилищ VMware Virtual SAN 6.2 мы забыли упомянуть о нововведении в части обработки файлов подкачки - Sparse Swap.
Как вы знаете при создании виртуальной машины в обычной инфраструктуре под нее резервируется файл *.vswp, который равен по размеру объему сконфигурированной оперативной памяти виртуальной машины (либо объему незарезервированной памяти, то есть разнице между сконфигурированной и зарезервированной памятью, если она указана в настройке reservation). Это нужно на случай, когда машине не хватает свободной физической памяти (в ситуации, если уже не спасают техники memory overcommit), и она начинает сбрасывать страницы памяти в своп-файл на диске.
То есть, если вы создали ВМ с оперативной памятью 4 ГБ, то столько же займет и файл подкачки для этой ВМ. А теперь посмотрим на инфраструктуру Virtual SAN: если у вас задан параметр FTT=1, то каждый дисковый объект (в том числе и файл *.vswp) будет задублирован (если у вас mirror-конфигурация).
Теперь посчитаем, сколько места съест своп 100 виртуальных машин, у каждой из которых 4 ГБ оперативной памяти и которые размещены в кластере VMware Virtual SAN с FTT=1 в зеркальной конфигурации:
100 ВМ * 4 ГБ * 2 (FTT равен 1) = 800 ГБ
Да, именно так - почти терабайт только под своп. Кому-то это покажется расточительством, поэтому в Virtual SAN сделали такую штуку, как Sparse Swap. Эта функция позволяет создавать файлы подкачки vswp как тонкие, то есть растущие по мере наполнения данными, диски.
Для того, чтобы включить опцию Sparse Swap, нужно выполнить следующую команду на хосте VMware ESXi:
Мы довольно часто пишем о технологии VMware VVols, которая позволяет организовывать виртуальные хранилища наиболее оптимально с точки зрения управления и производительности без файловой системы VMFS. Сегодня мы обсудим, как узнать, поддерживает ли ваш адаптер ввода-вывода технологию VMware VVols.
Начнем с того, почему адаптер и хранилище вообще должны ее поддерживать. Все просто - для доступа к томам VVols используется специальный служебный LUN, реализуемый в виде Protocol Endpoint (PE). Когда обычный FC-адаптер соединяется с хранилищем VMFS, он использует путь к LUN на базе адресов WWN, который состоит из номера HBA-адаптера, номера контроллера и, конечно же, LUN ID. Это все выглядит как vmhbaAdapter:CChannel:TTarget:LLUN (например, vmhba1:C0:T3:L1).
В случае с VVols и луном PE это уже работает несколько по-другому: появляются так называемые Secondary LUN IDs, которые адресуются как саблуны девайсом PE (secondary level IDs, SLLID). Этот Administrative LUN на устройстве PE не имеет емкости, но адресует тома VVols, которые находятся уже непосредственно на хранилище.
Сервер vCenter получает эти Secondary LUN IDs через механизм VASA Provider, реализованный через одноименный API. Далее уже хост ESXi (а точнее его I/O-адаптер, например, HBA-адаптер) работает в виртуальными машинами (а вернее с томами VVols) через Secondary LUN IDs (их, кстати, может быть не 255 как у LUN ID, а намного больше).
Надо отметить, что средства резервного копирования на уровне LUN не могут напрямую обратиться к этим Secondary LUN IDs, так как работа с ними идет только через хост VMware ESXi.
Так вот стандартная SCSI-команда REPORT_LUNS не подходит для обнаружения административных LUN, которые в отличие от LUN с данными, не имеют емкости. Поэтому VMware подала предложения в комитет T-10, отвечающий за SCSI-протокол, чтобы внести в его спецификацию некоторые изменения:
Самый простой способ узнать, поддерживает ли ваш FC/NFS-адаптер адресацию Secondary LUN IDs - это пойти в список совместимости VMware HCL:
В списке Features вы должны увидеть пункт Secondary LUNID (Enables VVols). Выберите его и посмотрите результат:
Тут уже видна подробная информация о драйвере и фича SLLID.
Далее можно заглянуть в ваш vmkernel.log и посмотреть нет ли там следующих строчек:
Sanity check failed for path vmhbaX:Y:Z. The path is to a VVol PE, but it goes out of adapter vmhbaX which is not PE capable. Path dropped.
Если есть - понятное дело, VVols не поддерживаются. Ну а в консоли сервера VMware ESXi параметры HBA-адаптера можно проверить следующей командой:
esxcli storage core adapter list
В колонке Capabilities будет видна строчка Second Level Lun ID, если поддержка VVols у вашего адаптера есть:
На стороне хранилища вам нужно убедиться, что VASA Provider включен и поддержка фич PE для VVols функционирует. Далее выполните следующую команду, чтобы убедиться, что хост ESXi видит девайс PE (обратите внимание, что он видится как диск):
esxcli storage core device list –pe-only
Если вы видите в строчке Is VVOL PE значение true, то значит все ок, и вы можете развертывать виртуальные машины на базе томов VVols.
Продолжаем рассказывать о технологиях компании StarWind, являющейся лидером в сфере решений для создания отказоустойчивых хранилищ под виртуальные машины на платформах VMware vSphere и Microsoft Hyper-V. Оказывается, прямо сейчас вы можете протестировать технологию VMware VVols совместно с решением StarWind Virtual SAN.
Для этого у компании StarWind есть специальный документ "StarWind Virtual SAN VVOLs Technical Preview Guide", рассказывающий о том, как попробовать виртуальные тома VVols для vSphere в режиме технологического превью в рамках тестовой инфраструктуры из одного хост-сервера.
Для тестирования нужно использовать виртуальный модуль StarWind VSA, который развертывается как виртуальная машина в формате OVF.
Для развертывания тестового стенда вам потребуется один сервер VMware ESXi 6.0 под управлением vCenter 6 в следующей минимальной конфигурации:
8 ГБ RAM
2GHz+ 64-bit x86 Dual Core CPU
2 vCPU, 4 ГБ RAM и 50 ГБ хранилища для машины StarWind
Компания VMware, оказывается, имеет интересный инструмент для расчета стоимости владения инфраструктурой хранения на базе локальных серверов VMware Virtual SAN TCO and Sizing Calculator. Понятно, что инструмент это больше маркетинговый, чем приложимый к реальному миру, но давайте все же взглянем на него. Напомним, кстати, также, что недавно была анонсирована новая версия VMware Virtual SAN 6.2.
Первое, что нам нужно ввести - это основные параметры инфраструктуры (можно выбрать между серверной виртуализацией и виртуализацией настольных ПК). Сначала нужно указать число виртуальных машин и число ВМ на сервер VMware ESXi. Далее можно использовать один для всех профиль виртуальной машины, а можно добавить несколько:
Если вы не знаете, что такое FTT (Failures to tolerates) - загляните вот в эту нашу заметку.
Далее мы вычисляем требуемую полезную емкость, необходимую для размещения виртуальных машин в кластерах Virtual SAN с учетом требуемого уровня отказоустойчивости:
Затем мы переходим к кастомизации так называемой "Ready Node" (об этом мы писали вот тут). Это типовой серверный узел, который будет исполнять как виртуальные машины, так и хранить их на своих локальных дисках.
Также в самом начале нужно задать "Performance profile", то есть типовую предполагаемую конфигурацию хранилища/производительности дисков для узла Virtual SAN. Внизу будет выведена примерная стоимость инфраструктуры хранения:
Кстати, у VMware есть инструмент Virtual SAN Ready Node Configurator, который поможет определиться с точной конфигурацией узла и создать спецификацию на него с учетом производителя серверов, которые вы обычно закупаете для своей инфраструктуры.
Ну а далее мы получаем overview из параметров, которыми будет обладать ваша виртуальная инфраструктура:
Ниже вы увидите распределение дискового пространства по VMDK-дискам, их репликам и прочим вспомогательным компонентам.
Внизу вы увидите конфигурацию хостов и кластера Virtual SAN, а также обобщенную спецификацию на узел. После этого переходим к параметрам расчета стоимости владения (TCO - total cost of ownership). Это такой метод сравнения затрат, когда вы сравниваете один способ реализации хранения машин без кластера хранилищ на базе локальных дисков с инфраструктурой Virtual SAN за определенный промежуток времени (обычно 3 или 5 лет).
Вводим параметры лицензирования и его тип, а также стоимость поддержки для Virtual SAN. Ниже вводим параметры текущей серверной конфигурации без VSAN:
Далее нам показывают "экономию" на трудозатратах (операционные издержки), а также на электропитании и охлаждении:
Ну а в конце приводится сводная таблица по капитальным и операционным затратам, полученная в сравнении использования Virtual SAN-конфигурации и развертывания традиционных дисковых массивов. Обратите внимание, что даже в дефолтном примере капитальные затраты с VSAN существенно выше:
Ниже идут различные графики про экономию денег в различных аспектах:
И в завершение - структура издержек на владение инфраструктурой хранения c VSAN и без него:
Инструмент интересный, но бесполезный. Пользуйтесь!
В этой заметке мы рассмотрим новые возможности решения для создания отказоустойчивых хранилищ на базе хост-серверов VMware Virtual SAN 6.2. Напомним, что о прошлой версии Virtual SAN 6.1, вышедшей осенью прошлого года, мы писали вот тут.
Итак, давайте посмотрим на новые возможности VSAN 6.2:
1. Дедупликация и сжатие данных.
Теперь обе этих технологии оптимизации хранилищ используются совместно, чтобы достичь наилучших результатов по стоимости хранения данных. Сначала данные виртуальных машин дедуплицируются на уровне дисковой группы, а потом сжимаются, что позволяет уменьшить исходный размер ВМ до 7 раз, в зависимости от типов нагрузки в гостевых ОС, по сравнению с первоначальным размещением.
Каждый vmdk хранит только оригинальные дисковые блоки:
2. Технология Erasure Coding (коррекция ошибок - "RAID из узлов").
В версии Virtual SAN 6.1 если вы используете параметр failures to tolerate =1 (FTT, зеркальная избыточность), то вам нужна двойная емкость в кластере. То есть, если будет 100 ГБ под виртуальные машины, то на хостах суммарная емкость должна составлять 200 ГБ.
По аналогии с RAID5/6 и другими типами RAID с чередованием, пространство хранения Virtual SAN 6.2 представляет собой "RAID из хостов ESXi". Таким образом, можно использовать схемы 3+1 или 4+2, которые позволят иметь лишь в 1,3 раза больше физического пространства (для первой схемы), чем полезной емкости. Об этом мы уже писали вот тут.
Вот интересная таблица соответствия параметров FTT, требований к инфраструктуре хранения и получаемых емкостей при различных типах RAID из хостов VMware ESXi:
3. Регулирование Quality of Service (QoS).
Теперь на уровне виртуальных дисков VMDK доступна регулировка полосы ввода-вывода на уровне IOPS:
Эти настройки могут быть применены через механизм политик хранилищ Storage Policy-Based Management (SPBM). Скорее всего, это будет востребовано в больших облачных инфраструктурах, особенно у сервис-провайдеров, которым необходимо обеспечивать различные уровни обслуживания своим клиентам. Также это позволяет создать механизм для того, чтобы рабочие нагрузки, размещенные на одном хранилище, не влияли друг на друга в моменты наибольшей нагрузки на подсистему хранения.
4. Техника Software Checksum.
Эта техника позволяет своевременно обнаруживать сбои, относящиеся к аппаратным и программным компонентам во время операций чтения/записи. Тут выделяются 2 типа сбоев: первый - "latent sector errors", который, как правило, свидетельствует о физической неисправности носителя, и второй - "silent data corruption", который происходит без предупреждения и может быть обнаружен только путем глубокой проверки поверхности накопителя.
5. Полноценная поддержка IPv6.
Теперь Virtual SAN поддерживает не только IPv4 и IPv6, но и смешанные окружения IPv4/IPv6 (для тех случаев, когда, например, на предприятии идет процесс миграции на новую версию протоколов).
6. Сервис мониторинга производительности.
Эти службы позволяют наблюдать за производительностью кластера Virtual SAN со стороны сервера vCenter. Теперь не обязательно идти в консоль vRealize Operations, чтобы решать базовые проблемы. Теперь в плане мониторинга доступны как высокоуровневые представления (Cluster latency, throughput, IOPS), так и более гранулярные (на базе дисков, попадания в кэш, статистика для дисковой группы и т.п.).
Также предусмотрена возможность предоставления данных о производительности кластера Virtual SAN сторонним сервисам через API. Для хранения событий используется собственная распределенная база данных, не зависящая от сервисов vCenter и хранящаяся в рамках кластера.
Компания StarWind, производитель лучшего решения Virtual SAN для создания программных отказоустойчивых хранилищ под виртуализацию, объявляет интересный конкурс. Все что вам нужно сделать, это поделиться своей историей о проекте по созданию гиперконвергентной архитектуры хранилищ (hyperconverged storage architecture), то есть архитектуры, где различные средства управления средой хранения сведены воедино в едином комплексе, а его масштабироание выполняется за счет добавления новых узлов.
Напомним, что у StarWind есть также собственное решение для создания гиперконвергентной инфраструктуры на базе серверов Dell, гипервизора Microsoft Hyper-V, ПО для хранилищ StarWind Virtual SAN, резервного копирования Veeam Backup and Replication, а также средств управления 5nine Hyper-V Manager. Поставляется оно в виде готового программно-аппаратного комплекса.
Итак, участвуйте в конкурсе StarWind и выиграйте 500 баксов:
Ваши истории появятся в блоге StarWind, а вы и ваши друзья и коллеги смогут проголосовать за них. Сами истории принимаются до 15 апреля, а уже 18 апреля будет объявлен победитель, который и получит 500 долларов. Те, кто займет второе и третье места, получат призы $300 и $150 соответственно.
Компания VMware в своем блоге, посвященном продуктам линейки VMware vSphere, представила интереснейшее доказательство, что кластер VMware Virtual SAN дает надежность "шесть девяток", то есть доступность данных 99,9999% времени в году. А это меньше, чем 32 секунды простоя в год.
Бесспорно, приведенное ниже "доказательство" основано на множестве допущений, поэтому заявление о шести девятках является несколько популистским. С моей точки зрения, гораздо более вероятно, что админ с бодуна не туда нажмет, или, например, в команде vmkfstools укажет не тот LUN и снесет все виртуальные машины на томе VMFS (привет, Антон!), чем откажет оборудование с дублированием компонентов. Но все же, рассмотрим это доказательство ниже.
Прежде всего, введем 2 понятия:
AFR – Annualized Failure Rate, то есть вероятность отказа в год (носителя данных или другого компонента), выраженная в процентах.
MTBF – Mean Time Between Failures (среднее время между отказами). Это время в часах.
Эти 2 величины взаимосвязаны и выражаются одна через другую в соответствии с формулой:
AFR = 1/(MTBF/8760) * 100%
Обычно, как HDD, так и SSD накопители, имеют AFR от 0.87% до 0.44%, что дает от 1 000 000 до 2 000 000 часов MTBF. Далее для примера берут диск 10K HDD от Seagate (популярная модель ST1200MM0088), для которой AFR равен 0.44% (см. вторую страницу даташита) или 2 миллиона часов в понятии MTBF. Ну и взяли популярный SSD Intel 3710 для целей кэширования, который также имеет MTBF на 2 миллиона часов.
Для того, чтобы вычислить время доступности данных на таких накопителях, нужно понимать время, которое необходимо для восстановления бэкапа на новый накопитель в случае сбоя. По консервативным оценкам - это 24 часа. Таким образом, доступность данных будет равна:
2 000 000/ (2 000 000 + 24) = 0,99998
То есть, 4 девятки. Но диск - это еще не весь сервис. Есть еще надежность дискового контроллера, самого хост-сервера и стойки в целом (по питанию). VMware запросила данные у производителей и получила следующие параметры доступности:
Вот, доступность уже 3 девятки, что эквивалентно 8,76 часов простоя в год. Не так плохо, но это слишком оптимистичные значения - на деле есть прочие факторы, влияющие на доступность, поэтому уберем последнюю цифру из долей для доступности каждого из компонентов:
Получается 2 девятки, а это 3,65 дня простоя в год, что уже довольно критично для многих бизнесов.
Ну а теперь применим технологию VMware Virtual SAN, которая дублирует данные на уровне виртуальных машин и отдельных виртуальных дисков. Если мы используем параметр FTT (Numbers of failures to tolerate) равный 1, что подразумевает хранение одной реплики данных, то вероятность недоступности хранилища Virtual SAN данных будет равна вероятности отказа 2-х хранилищ одновременно, то есть:
(1-0.997)^2 = 0.00000528
Ну а доступность в данном случае равна:
1-0.00000528 = 0.999994
То есть, уже 5 девяток. Но это доступность для одного объекта VSAN, а отдельная виртуальная машина обычно имеет несколько объектов, допустим, 10. Тогда ее доступность будет равна:
0.999994^10 = 0.99994
В итоге, 4 девятки. Это 52,56 минуты простоя в год. В зависимости от того, сколько объектов у вас будет на одну ВМ, вы будете иметь доступность от 4 до 5 девяток.
А теперь возьмем FTT=2, то есть конфигурацию, когда имеется 2 дополнительных копии данных для каждого объекта в кластере Virtual SAN. В этом случае вероятность полного отказа всех трех копий данных:
(1-0.997)^3 = 0.00000001214
А доступность для ВМ с десятью объектами:
0.999999988^10 = 0.999999879
То есть, те самые 6 девяток, о которых говорится на слайде. Конечно, все это допущения, фантазии и игра с вероятностями, но читать это все равно интересно. Еще более интересно то, что оригинал этой статьи написала женщина)
Таги: VMware, Virtual SAN, HA, VSAN, Enterprise, Blog, Availability, Storage
Тем из вас, кто администрирует инфраструктуру Microsoft, может оказаться интересным технологический блог компании StarWind Software, которая производит лучшее средство для создания отказоустойчивых хранилищ для инфраструктуры Hyper-V - Virtual SAN.
В своем блоге сотрудники компании рассказывают об интересных фишках, например, есть посты от основателя и CTO компании Антона Коломейцева о том, как сделать бесплатный SMB 3.0 сервер на бесплатном Hyper-V Server, да еще и в кластерной конфигурации:
Интересная статья от Дункана Эппинга была опубликована в его блоге пару недель назад. Если вы хотите использовать виртуальные тома VVols, которые обладают некоторыми преимуществами по сравнению с традиционной файловой системой VMware VMFS, то для некоторых систем, поддерживающих механизм VASA (vSphere API for Storage Awareness), потребуется использовать внешний виртуальный модуль VASA Vendor Provider (VP). То есть, некоторые аппаратные хранилища уже содержат в себе готовые модули и прошитые в них модули VP, а вот для некоторых нужно запускать и поддерживать специальную виртуальную машину, выполняющую сервисные функции при работе виртуальных машин с хранилищами VVols.
Прежде всего VP используется для выполнения операции Bind (привязка машины к VVol), которая инициируется при запуске виртуальной машины. В этом случае VP создает точку доступа ввода-вывода (IO access point) для виртуального тома VVol на выбранном Protocol Endpoint (PE). Без этой операции машина не запустится, из чего следует, что критически важно поддерживать виртуальную машину с VP непрерывно доступной. У разных вендоров используются разные уровни доступности:
Кто-то выпускает модуль с возможностью active/standby или active/active-конфигурации виртуальных машин на разных хостах.
Ну а кто-то надеется на встроенные механизмы обеспечения отказоустойчивости VMware HA и VMware Fault Tolerance (FT).
Очевидно, что если вы выбираете хранилище с внешним VP, то очень желательно, чтобы там был реализован первый вариант обеспечения доступности. Ну и нельзя помещать виртуальную машину с VASA VP на том VVol, чтобы не оказаться в ловушке невозможности запуска этой виртуальной машины.
Со временем VMware планирует включить операции bind/unbind в стандарт T10 SCSI, и сервисная виртуальная машина будет не нужна, но эти вещи, как вы понимаете, делаются не быстро, поэтому пока обеспечивайте отказоустойчивость виртуальных модулей VP, по крайней мере, с помощью технологий VMware HA и VMware Fault Tolerance.
И да, в комментарии пишут, что у одного админа получилось так, что машина с VP просто перестала выполнять команды, хотя сама ВМ работала. В результате продуктивные ВМ было не запустить. Поэтому имеет смысл задуматься и об обеспечении отказоустойчивости на уровне компонентов VP (может, как-нибудь проверять скриптами его работоспособность?).
Таги: VMware, VVOls, HA, FT, Storage, vSphere, Hardware
Мы часто пишем о том, что снапшоты в VMware vSphere - это плохо (за исключением случаев, когда они используются для горячего резервного копирования виртуальных машин и временного сохранения конфигурации ВМ перед обновлением).
Однако их использование в крупных инфраструктурах неизбежно. Рано или поздно возникает необходимость удаления/консолидации снапшотов виртуальной машины (кнопка Delete All в Snapshot Manager), а процесс этот достаточно длительный и требовательный к производительности хранилищ, поэтому неплохо бы заранее знать, сколько он займет.
Напомним, что инициирование удаления снапшотов в vSphere Client через функцию Delete All приводит к их удалению из GUI сразу же, но на хранилище процесс идет долгое время. Но если в процесс удаления возникнет ошибка, то файлы снапшотов могут остаться на хранилище. Тогда нужно воспользоваться функцией консолидации снапшотов (пункт контекстного меню Consolidate):
О процессе консолидации снапшотов мы также писали вот тут. Удаление снапшотов (как по кнопке Delete All, так и через функцию Consolidate) называется консолидацией.
Сначала посмотрим, какие факторы влияют на время процесса консолидации снапшотов виртуальной машины:
Размер дельта-дисков - самый важный параметр, это очевидно. Чем больше данных в дельта-диске, тем дольше их нужно применять к основному (базовому) диску.
Количество снапшотов (число дельта-файлов) и их размеры. Чем больше снапшотов, тем больше метаданных для анализа перед консолидацией. Кроме того, при нескольких снапшотах консолидация происходит в несколько этапов.
Производительность подсистемы хранения, включая FC-фабрику, Storage Processor'ы хранилищ, LUN'ы (число дисков в группе, тип RAID и многое другое).
Тип данных в файлах снапшотов (нули или случайные данные).
Нагрузка на хост-сервер ESXi при снятии снапшота.
Нагрузка виртуальной машины на подсистему хранения в процессе консолидации. Например, почтовый сервер, работающий на полную мощность, может очень долго находится в процессе консолидации снапшотов.
Тут надо отметить, что процесс консолидации - это очень требовательный к подсистеме ввода-вывода процесс, поэтому не рекомендуется делать это в рабочие часы, когда производственные виртуальные машины нагружены.
Итак, как можно оценивать производительность процесса консолидации снапшотов:
Смотрим на производительность ввода-вывода хранилища, где находится ВМ со снапшотами.
Для реализации этого способа нужно, чтобы на хранилище осталась только одна тестовая виртуальная машина со снапшотами. С помощью vMotion/Storage vMotion остальные машины можно с него временно убрать.
1. Сначала смотрим размер файлов снапшотов через Datastore Browser или с помощью следующей команды:
ls -lh /vmfs/volumes/DATASTORE_NAME/VM_NAME | grep -E "delta|sparse"
2. Суммируем размер файлов снапшотов и записываем. Далее находим LUN, где размещена наша виртуальная машина, которую мы будем тестировать (подробнее об этом тут).
3. Запускаем команду мониторинга производительности:
# esxtop
4. Нажимаем клавишу <u> для переключения в представление производительности дисковых устройств. Для просмотра полного имени устройства нажмите Shift + L и введите 36.
5. Найдите устройство, на котором размещен датастор с виртуальной машиной и отслеживайте параметры в колонках MBREAD/s и MBWRTN/s в процессе консолидации снапшотов. Для того, чтобы нужное устройство было вверху экрана, можно отсортировать вывод по параметру MBREAD/s (нажмите клавишу R) or MBWRTN/s (нажмите T).
Таким образом, зная ваши параметры производительности чтения/записи, а также размер снапшотов и время консолидации тестового примера - вы сможете оценить время консолидации снапшотов для других виртуальных машин (правда, только примерно того же профиля нагрузки на дисковую подсистему).
Смотрим на производительность конкретного процесса консолидации снапшотов.
Это более тонкий процесс, который можно использовать для оценки времени снапшота путем мониторинга самого процесса vmx, реализующего операции со снапшотом в памяти сервера.
1. Запускаем команду мониторинга производительности:
# esxtop
2. Нажимаем Shift + V, чтобы увидеть только запущенные виртуальные машины.
3. Находим ВМ, на которой идет консолидация.
4. Нажимаем клавишу <e> для раскрытия списка.
5. Вводим Group World ID (это значение в колонке GID).
6. Запоминаем World ID (для ESXi 5.x процесс называется vmx-SnapshotVMX, для ранних версий SnapshotVMXCombiner).
7. Нажимаем <u> для отображения статистики дискового устройства.
8. Нажимаем <e>, чтобы раскрыть список и ввести устройство, на которое пишет процесс консолидации VMX. Что-то вроде naa.xxx.
9. Смотрим за процессом по World ID из пункта 6. Можно сортировать вывод по параметрам MBREAD/s (клавиша R) или MBWRTN/s (клавиша T).
10. Отслеживаем среднее значение в колонке MBWRTN/s.
Это более точный метод оценки и его можно использовать даже при незначительной нагрузке на хранилище от других виртуальных машин.
Продолжаем рассказывать о решении номер 1 для создания программных хранилищ под виртуализацию VMware и Microsoft - StarWind Virtual SAN. Сегодня мы расскажем о том, как корректно настроить механизм доступа к хранилищам по нескольким путям MPIO (Multi-Path Input/Output) на сервере хранения Windows Server 2012.
Сначала необходимо убедиться, что возможность MPIO установлена на сервере, и, если нет, то установить ее:
Открываем Server Manager.
Нажимаем кнопку "Manage" в правом верхнем углу и выбираем "Add Roles and Features".
Нажимаем Next в первой странице мастера.
В части Installation Type выбираем "Role-based or feature-based installation".
На странице Server Selection выбираем нужный сервер, где хотим включить MPIO (по умолчанию этот сервер).
В разделе Features отмечаем галкой "Multipath I/O" и жмем кнопку "Install".
После того, как вы добавили возможность MPIO на Windows Server, нужно включить ее поддержку для iSCSI-устройств, которые использует StarWind Virtual SAN:
Откройте настройку MPIO в средствах администрирования сервера.
Нажмите на вкладку "Discover Multi-Paths".
Поставьте галочку напротив "Add support for iSCSI devices".
Перезагрузите сервер.
Затем нужно настроить политику доступа по нескольким путям. StarWind рекомендует использовать политику "Fail Over Only", если сумма пропускных способностей ваших путей составляет менее 10 Гбит/с. В противном случае стоит использовать политику Round Robin в целях повышения производительности.
Более подробно о настройке MPIO для StarWind рассказано тут.
В новой книге Фрэнка на 300 страницах раскрываются следующие моменты, касающиеся производительности подсистемы хранения платформ виртуализации, построенной на базе локальных дисков хост-серверов:
Новая парадигма построения виртуального датацентра с точки зрения систем хранения
Архитектура решения FVP
Ускорение доступа к данным
Технология непрерывной доступности Fault Tolerance
Технология Flash
Техники доступа к памяти
Настройка кластера решения FVP
Сетевой дизайн инфраструктуры локальных хранилищ
Внедрение и пробная версия решения FVP
Дизайн инфраструктуры хранилищ
Несмотря на то, что книга рассматривает в качестве основного продукта решение FVP от компании PernixData, ее интересно читать и с точки зрения понимания архитектуры и производительности подобных решений.
Если вы посмотрите в документ VSAN Troubleshooting Reference Manual (кстати, очень нужный и полезный), описывающий решение проблем в отказоустойчивом кластере VMware Virtual SAN, то обнаружите там такую расширенную настройку, как VSAN.ClomMaxComponentSizeGB.
Когда кластер VSAN хранит объекты с данными виртуальных дисков машин, он разбивает их на кусочки, растущие по мере наполнения (тонкие диски) до размера, указанного в данном параметре. По умолчанию он равен 255 ГБ, и это значит, что если у вас физические диски дают полезную емкость меньше данного объема (а точнее самый маленький из дисков в группе), то при достижении тонким диском объекта предела физической емкости вы получите вот такое сообщение:
There is no more space for virtual disk XX. You might be able to continue this session by freeing disk space on the relevant volume and clicking retry.
Если, например, у вас физический диск на 200 ГБ, а параметры FTT и SW равны единице, то максимально объект виртуального диска машины вырастет до этого размера и выдаст ошибку. В этом случае имеет смысл выставить настройку VSAN.ClomMaxComponentSizeGB на уровне не более 80% емкости физического диска (то есть, в рассмотренном случае 160 ГБ). Настройку эту нужно будет применить на каждом из хостов кластера Virtual SAN.
Как это сделать (более подробно об этом - в KB 2080503):
В vSphere Web Client идем на вкладку Manage и кликаем на Settings.
Под категорией System нажимаем Advanced System Settings.
Выбираем элемент VSAN.ClomMaxComponentSizeGB и нажимаем иконку Edit.
Устанавливаем нужное значение.
Надо отметить, что изменение этой настройки работает только для кластера VSAN без развернутых на нем виртуальных машин. Если же у вас уже продакшен-инфраструктура столкнулась с такими трудностями, то вы можете воспользоваться следующими двумя способами для обхода описанной проблемы:
1. Задать Object Space Reservation в политике хранения (VM Storage Policy) таким образом, чтобы дисковое пространство под объекты резервировалось сразу (на уровне 100%). И тогда VMDK-диски будут аллоцироваться целиком и распределяться по физическим носителям по мере необходимости.
2. Задать параметр Stripe Width в политиках VM Storage Policy таким образом, чтобы объекты VMDK распределялись сразу по нескольким физическим накопителям.
Фишка еще в том, что параметрVSAN.ClomMaxComponentSizeGB не может быть выставлен в значение, меньшее чем 180 ГБ, а значит если у вас носители меньшего размера (например, All-Flash конфигурация с дисками меньше чем 200 ГБ) - придется воспользоваться одним из этих двух способов, чтобы избежать описанной ошибки. Для флеш-дисков 200 ГБ установка значения в 180 ГБ будет ок, несмотря на то, что это уже 90% физической емкости.
Представляем гостевой пост компании 1cloud, предоставляющей услуги в области хостинга виртуальных машин по модели IaaS. С падением цен на SSD все больше компаний предлагают массивы, целиком построенные на флеш-памяти, но действительно ли они лучше гибридных массивов, содержащих как твердотельные накопители, так и жесткие диски?
Многие из вас, следящие за новостями о лучшем продукте для создания отказоустойчивых хранилищ StarWind Virtual SAN, часто задаются вопросом - а чем это решение лучше существующих аналогов от VMware и Microsoft? Первый и наиболее очевидный ответ - цена. Просто посмотрите на то, сколько стоит VMware VSAN, и сравните это со стоимостью лицензий StarWind. Разницу вы почувствуете сразу.
Но это еще не все. Компания StarWind выпустила полезный каждому сомневающемуся документ "StarWind Virtual SAN: Differentiation [from competitors]", в котором весьма подробно рассмотрены преимущества продукта перед решениями от маститых вендоров.
Например, почему StarWind Virtual SAN лучше VMware Virtual SAN:
Для работы отказоустойчивых хранилищ StarWind нужно всего 2 узла (VMware требует минимум 3). Плюс StarWind не требует какой-то особенной инфраструктуры типа поддержки 10G Ethernet или SSD-дисков. У StarWind все проще.
VMware Virtual SAN лицензируется по числу процессоров ESXi плюс требуются лицензии на сам ESXi. У StarWind лицензия выйдет дешевле - вы можете лицензировать по числу узлов кластера хранилищ, либо весь датацентр сразу, и использовать бесплатные издания ESXi.
Кластер VMware Virtual SAN вы можете использовать только для платформы vSphere, а StarWind Virtual SAN можно использовать для хранения виртуальных машин на базе любого гипервизора - хоть ESXi, хоть Hyper-V, хоть XenServer.
StarWind Virtual SAN - это продукт, который сейчас находится в 8-й версии, а Virtual SAN - это всего лишь вторая версия решения. Поскольку это решение относится к самому нижнему уровню сервисов хранения датацентра, надежность работы решения является определяющим факторов.
Более подробно об этом и других продуктах для сравнения, в частности, Microsoft Storage Spaces, Microsoft Scale-Out File Server, HP Lefthand VSA, DataCore SANsymphony, Maxta и PernixData, вы можете узнать непосредственно из документа.
Некоторое время назад мы писали об очень серьезном баге в технологии Changed Block Tracking, обеспечивающей работу инкрементального резервного копирования виртуальных машин VMware vSphere 6. Баг заключался в том, что операции ввода-вывода, сделанные во время консолидации снапшота ВМ в процессе снятия резервной копии, могли быть потеряны. Для первого бэкапа в этом нет ничего страшного, а вот вызываемая во второй раз функция QueryDiskChangedAreas технологии CBT не учитывала потерянные операции ввода-вывода, а соответственно при восстановлении из резервной копии такой бэкап был неконсистентным.
Мы писали про временное решение, заключающееся в отключении технологии CBT при снятии резервных копий продуктом Veeam Backup and Replication, но оно, конечно же, было неприемлемым, так как скорость бэкапов снижалась в разы, расширяя окно резервного копирования до неприличных значений.
И вот, наконец, вышло исправление этого бага, описанное в KB 2137545. Это патч для сервера VMware ESXi, который распространяется в виде стандартного VIB-пакета в сжатом zip-архиве.
Чтобы скачать патч, идите по этой ссылке, выберите продукт "ESXi Embedded and Installable" и введите в поле Enter Bulletin Number следующую строчку:
ESXi600-201511401-BG
Нажмите Search, после чего скачайте обновленный билд VMware ESXi 6.0 по кнопке Download:
Про патч в формате VIB-пакета написано вот тут, а про сам обновленный релиз ESXi вот тут. Для установки VIB на сервере ESXi используйте следующую команду:
Как-то раз мы писали про баг в VMware vSphere 5.5 (и более ранних версиях), заключавшийся в том, что при увеличении виртуальных дисков машин с включенной технологией Changed Block Tracking (CBT) их резервные копии оказывались невалидными и не подлежащими восстановлению. Эта ошибка была через некоторое время пофикшена.
Суть критического бага в том, что операции ввода-вывода, сделанные во время консолидации снапшота ВМ в процессе снятия резервной копии, могут быть потеряны. Для первого бэкапа в этом нет ничего страшного, а вот вызываемая во второй раз функция QueryDiskChangedAreas технологии CBT не учитывает потерянные операции ввода-вывода, а соответственно при восстановлении из резервной копии такой бэкап будет неконсистентным. То есть баг намного более серьезный, чем был в версии vSphere 5.5 (там надо были задеты только ВМ, диски которых увеличивали, а тут любая ВМ подвержена багу).
На данный момент решения этой проблемы нет, надо ждать исправления ошибки. Пока VMware предлагает на выбор 3 варианта:
Сделать даунгрейд хостов ESXi на версию 5.5, а версию virtual hardware 11 понизить на 10.
Делать полные бэкапы виртуальных машин (full backups) вместо инкрементальных.
Выключать виртуальные машины во время инкрементального бэкапа, чтобы у них не было никаких IO, которые могут потеряться.
Как вы понимаете, ни один из этих вариантов неприемлем в условиях нормальной работы производственной среды. Мы оповестим вас об исправлении ошибки, ну а пока поздравляем службу контроля качества компании VMware с очередной лажей!
P.S. Пока делайте полные бэкапы критичных систем. И следите за новостями от Veeam.
Сегодняшняя статья расскажет вам ещё об одной функции моего PowerShell-модуля для управления виртуальной инфраструктурой VMware - Vi-Module. Первая статья этой серии с описанием самого модуля находится здесь. Функция Convert-VmdkThin2EZThick. Как вы уже поняли из её названия, функция конвертирует все «тонкие» (Thin Provision) виртуальные диски виртуальной машины в диски типа Thick Provision Eager Zeroed.
Многие из вас знают, что в VMware vSphere есть такой режим работы виртуальных дисков, как Raw Device Mapping (RDM), который позволяет напрямую использовать блочное устройство хранения без создания на нем файловой системы VMFS. Тома RDM бывают pRDM (physical) и vRDM (virtual), то есть могут работать в режиме физической и виртуальной совместимости. При работе томов в режиме виртуальной совместимости они очень похожи на VMFS-тома (и используются очень редко), а вот режим физической совместимости имеет некоторые преимущества перед VMFS и довольно часто используется в крупных предприятиях.
Итак, для чего может быть полезен pRDM:
Администратору требуется использовать специальное ПО от производителя массива, которое работает с LUN напрямую. Например, для создания снапшотов тома, реплики базы данных или ПО, работающее с технологией VSS на уровне тома.
Старые данные приложений, которые еще не удалось перенести в виртуальные диски VMDK.
Виртуальная машина нуждается в прямом выполнении команд к тому RDM (например, управляющие SCSI-команды, которые блокируются слоем SCSI в VMkernel).
Перейдем к рассмотрению схемы решения VMware Site Recovery Manager (SRM):
Как вы знаете, продукт VMware SRM может использовать репликацию уровня массива (синхронную) или технологию vSphere Replication (асинхронную). Как мы писали вот тут, если вы используете репликацию уровня массива, то поддерживаются тома pRDM и vRDM, а вот если vSphere Replication, то репликация физических RDM будет невозможна.
Далее мы будем говорить о репликации уровня дискового массива томов pRDM, как о самом часто встречающемся случае.
Если говорить об уровне Storage Replication Adapter (SRA), который предоставляется производителем массива и которым оперирует SRM, то SRA вообще ничего не знает о томах VMFS, то есть о том, какого типа LUN реплицируется, и что на нем находится.
Он оперирует понятием только серийного номера тома, в чем можно убедиться, заглянув в XML-лог SRA:
Тут видно, что после серийного номера есть еще и имя тома - в нашем случае SRMRDM0 и SRMVMFS, а в остальном устройства обрабатываются одинаково.
SRM обрабатывает RDM-диски похожим на VMFS образом. Однако RDM-том не видится в качестве защищаемых хранилищ в консоли SRM, поэтому чтобы добавить такой диск, нужно добавить виртуальную машину, к которой он присоединен, в Protection Group (PG).
Допустим, мы добавили такую машину в PG, а в консоли SRM получили вот такое сообщение:
Device not found: Hard disk 3
Это значит одно из двух:
Не настроена репликация RDM-тома на резервную площадку.
Репликация тома настроена, но SRM еще не обнаружил его.
В первом случае вам нужно заняться настройкой репликации на уровне дискового массива и SRA. А во втором случае нужно пойти в настройки SRA->Manage->Array Pairs и нажать там кнопку "Обновить":
Этот том после этого должен появиться в списке реплицируемых устройств:
Далее в настройках защиты ВМ в Protection Group можно увидеть, что данный том видится и защищен:
Добавление RDM-диска к уже защищенной SRM виртуальной машине
Если вы просто подцепите диск такой ВМ, то увидите вот такую ошибку:
There are configuration issues with associated VMs
Потому, что даже если вы настроили репликацию RDM-диска на уровне дискового массива и SRA (как это описано выше), он автоматически не подцепится в настройки - нужно запустить редактирование Protection Group заново, и там уже будет будет виден RDM-том в разделе Datastore groups (если репликация корректно настроена):
Помните также, что SRM автоматически запускает обнаружение новых устройств каждые 24 часа по умолчанию.
Гостевая статья нашего спонсора - компании ИТ-ГРАД, предоставляющей услуги виртуальных машин VMware в аренду. В этой статье речь пойдет о плюсах интеграции среды виртуализации VMware и систем хранения NetApp. В частности, продолжим разбираться с VAAI и посмотрим, как использование такой связки может помочь в проектах по разработке ПО.
Больше 5 лет назад мы писали о технологии VMware Storage I/O Control (SIOC), которая позволяет приоритизировать ввод-вывод для виртуальных машин в рамках хоста, а также обмен данными хостов ESXi с хранилищами, к которым они подключены. С тех пор многие администраторы применяют SIOC в производственной среде, но не все из них понимают, как именно это работает.
На эту тему компания VMware написала два интересных поста (1 и 2), которые на практических примерах объясняют, как работает SIOC. Итак, например, у нас есть вот такая картинка:
В данном случае мы имеем хранилище, отдающее 8000 операций ввода-вывода в секунду (IOPS), к которому подключены 2 сервера ESXi, на каждом из которых размещено 2 виртуальных машины. Для каждой машины заданы параметры L,S и R, обозначающие Limit, Share и Reservation, соответственно.
Напомним, что:
Reservation - это минимально гарантированная производительность канала в операциях ввода-вывода (IOPS). Она выделяется машине безусловно (резервируется для данной машины).
Shares - доля машины в общей полосе всех хостов ESXi.
Limit - верхний предел в IOPS, которые машина может потреблять.
А теперь давайте посмотрим, как будет распределяться пропускная способность канала к хранилищу. Во-первых, посчитаем, как распределены Shares между машинами:
Общий пул Shares = 1000+2500+500+1000 = 5000
Значит каждая машина может рассчитывать на такой процент канала:
Если смотреть с точки зрения хостов, то между ними канал будет поделен следующим образом:
ESX1 = 3500/5000 = 70%
ESX2 = 1500/5000 = 30%
А теперь обратимся к картинке. Допустим у нас машина VM1 простаивает и потребляет только 10 IOPS. В отличие от планировщика, который управляет памятью и ее Shares, планировщик хранилищ (он называется mClock) работает по другому - неиспользуемые иопсы он пускает в дело, несмотря на Reservation у это виртуальной машины. Ведь он в любой момент может выправить ситуацию.
Поэтому у первой машины остаются 1590 IOPS, которые можно отдать другим машинам. В первую очередь, конечно же, они будут распределены на этом хосте ESXi. Смотрим на машину VM2, но у нее есть LIMIT в 5000 IOPS, а она уже получает 4000 IOPS, поэтому ей можно отдать только 1000 IOPS из 1590.
Следовательно, 590 IOPS уйдет на другой хост ESXi, которые там будут поделены в соответствии с Shares виртуальных машин на нем. Таким образом, распределение IOPS по машинам будет таким:
Все просто и прозрачно. Если машина VM1 начнет запрашивать больше канала, планировщик mClock начнет изменять ситуацию и приведет ее к значениям, описанным выше.
В этой заметке мы расскажем еще об одной важной новой функции пакета продуктов - Scale-out Backup Repository. Ранее пользователи Veeam Backup and Replication использовали различные устройства для бэкап-репозиториев, чтобы хранить резервные копии виртуальных машин. Это могли быть локальные диски серверов, файловые хранилища, разделы на СХД и многое другое. Так как инфраструктура растет постепенно и, зачастую, неоднородно, в итоге у администраторов оказывался примерно вот такой наборчик бэкап-репозиториев:
Эта картина плоха со всех сторон. Во-первых, таким большим числом репозиториев трудно управлять - надо следить за их доступностью, поддерживать схемы именования, смотреть за свободным пространством и т.п. Все это создает серьезные административные проблемы в большой инфраструктуре.
Во-вторых, число бэкап-задач, которые создает администратор - как минимум равно числу бэкап-репозиториев, так как одна задача не может охватывать 2 репозитория.
Ну и, в третьих, посмотрите на свободное место на каждом репозитории - его весьма много (если брать среднее, то 30%). То есть, мы используем вполовину больше того, что нам требуется.
Эта ситуация давно волновала администраторов, и в новой версии Veeam Availability Suite v9 представлена функция Scale-out Backup Repository, которая позволяет объединить все репозитории в один мета-объект (global pool), который можно задавать в качестве целевого хранилища бэкапов. Для расширения такого пула потребуется лишь добавить экстент (extent), который повысит совокупную емкость глобального репозитория. Удобно и не надо перераспределять целевые хранилища, чтобы найти свободное место под новые бэкапы.
Таким образом, можно использовать единственную задачу резервного копирования всех нужных вам машин, указав в качестве целевого этот глобальный репозиторий. При этом глобальный репозиторий можно наращивать хранилищами любого типа - локальные диски серверов, сетевые хранилища и даже, например, дедуплицирующие физические или виртуальные модули (dedup appliances) - все это для Veeam Backup and Replication будет поддерживаться и работать.
При добавлении экстента можно указать, принимает ли он полные бэкапы (full backups), инкрементальные бэкапы (incremental backups) или оба типа. Например, для инкрементальных бэкапов можно использовать быстрые all-flash хранилища, а для полных бэкапов можно применять dedup appliance в качестве целевого хранилища резервных копий, где они будут лежать в дедуплицированном виде. Возможности для фантазии тут безграничны.
Также происходит, по-сути, появление бэкап-облака, нового уровня абстракции, которое представляется пользователям как единое пространство хранения резервных копий, а его обслуживанием занимается бэкап-администратор. Теперь владельцы систем могут сами настраивать бэкап своих виртуальных машин в единое облако, не думая, какой репозиторий выбрать, а бэкап-администратор уже займется оптимизацией своего облака.
Более подробно об этом всем написано в блоге Veeam.
Бывает так, что на виртуальной или физической машине заканчивается свободное место на диске, где расположена база данных для VMware vCenter. Чаще всего причина проста - когда-то давно кто-то не рассчитал размер выделенного дискового пространства для сервера, где установлен vCenter и SQL Server Express.
В этом случае в логах (в SQL Event Log Viewer и SQL Log) будут такие ошибки:
Could not allocate space for object ‘dbo.VPX_EVENT_ARG’.’PK_VPX_EVENT_ARG’ in database ‘VIM_VCDB’ because the ‘PRIMARY’ filegroup is full. Create disk space by deleting unneeded files, dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for existing files in the filegroup.
CREATE DATABASE or ALTER DATABASE failed because the resulting cumulative database size would exceed your licensed limit of 4096 MB per database.
Could not allocate space for object 'dbo.VE_event_historical'.'PK__VE_event_histori__00551192' in database 'ViewEvent' because the 'PRIMARY' filegroup is full. Create disk space by deleting unneeded files, dropping objects in the filegroup, adding additional files tothe filegroup, or setting autogrowth on for existing files in the filegroup.
Решение в данном случае простое - нужно выполнить операцию по очистке старых данных из БД SQL Server (Shrink Database). Делается это в SQL Management Studio - нужно выбрать базу данных и выполнить Tasks -> Shrink -> Database:
Смотрим, что получится и нажимаем Ok:
Также в KB 1025914 вы найдете более детальную информацию о том, как почистить базы данных Microsoft SQL Server и Oracle. Там же есть и скрипты очистки БД:
Мероприятие пройдет 20 октября в 22-00 по московскому времени.
На вебинаре будет рассказано, почему в гиперконвергентной инфраструктуре лучше иметь 3 узла для организации отказоустойчивых хранилищ. Напомним, что мы уже писали об этой архитектуре вот тут.
Этой статьёй я хочу открыть серию статей, целью каждой из которых будет описание одной из написанных мной функций PowerCLI или так называемых командлетов (cmdlets), предназначенных для решения задач в виртуальных инфраструктурах, которые невозможно полноценно осуществить с помощью только лишь встроенных функций PowerCLI. Все эти функции будут объединены в один модуль - Vi-Module. Как им пользоваться, можете почитать здесь.
Иногда администраторам хранилищ в VMware vSphere требуется передать логический том LUN или локальный диск сервера под другие цели (например, отдать не под виртуальные системы или передать в другой сегмент виртуальной инфраструктуры). В этом случае необходимо убедиться, что все данные на этом LUN удалены и не могут быть использованы во вред компании.
Раньше это приходилось выполнять путем загрузки из какого-нибудь Linux LiveCD, которому презентован данный том, и там удалять его данные и разделы. А в VMware vSphere 6 Update 1 появился более простой способ - теперь эта процедура доступна из графического интерфейса vSphere Web Client в разделе Manage->Storage Adapters:
Теперь просто выбираем нужный адаптер подсистемы хранения и нажимаем Erase для удаления логических томов устройства (будут удалены все логические тома данного устройства):
Теперь можно использовать этот локальный диск по другому назначению, например, отдать кластеру VSAN.
Ну и также отметим, что в следующей версии утилиты ESXi Embedded Host Client компания VMware сделает возможность не только удаления таблицы разделов, но и добавит средства их редактирования:
Компания StarWind Software, известная своим лучшим продуктом для созданиях отказоустойчивых хранилищ для VMware vSphere и Microsoft Hyper-V, на отдельном подсайте сделала доступной базу знаний StarWind Knowledge Base.
Статьи KB разбиты по категориям, по всей базе доступен поиск, к каждой статье есть тэги. На данный момент в базе 41 статья, среди которых есть несколько полезных в плане обучения, например, Logical block size или StarWind LSFS FAQ.
Скачать пробную версию продукта StarWind Virtual SAN можно по этой ссылке.
Мы уже писали о новой версии решения VMware Virtual SAN 6.1, предназначенной для создания отказоустойчивых хранилищ на платформе VMware vSphere. После того, как издания "hybrid" и "all-flash" были переименованы в "standard" и "advanced" соответственно, у пользователей появилось несколько вопросов о функциональности этих изданий.
Начнем с того, что в целом все осталось как было:
VSAN
STANDARD
VSAN
ADVANCED
VSAN FOR ROBO
(25 VM PACK)
Политики хранилищ Storage Policy Based Management (SPBM)
Итак, мы видим, что отличий у изданий Standard и Advanced теперь два:
Для конфигураций только из SSD-дисков серверов можно использовать только издание Advanced.
Для "растянутых" кластеров также можно использовать только издание Advanced. Но тут есть нюанс - растянутым кластером можно считать географически разнесенные площадки (на уровне двух разных зданий). Если у вас кластер на уровне стоек в двух серверных или на разных этажах - растянутым он не считается.
Также появилось издание VSAN for ROBO (remote or branch offices). Это издание позволяет использовать решение VSAN компаниям имеющую сеть небольших филиалов, где нет большого числа хостов ESXi. Для такой лицензии можно запустить не более 25 виртуальных машин в рамках филиала и одной ROBO-лицензии.
Здесь кластеры строятся на уровне каждого из филиалов, а witness-компонент (виртуальный модуль, следящий за состоянием кластера) располагается в инфраструктуре центрального офиса. Причем на каждый кластер VSAN нужно по отдельному witness'у. Этот самый witness позволяет построить кластер на базе всего двух узлов, а не трех, так как он следит за ситуацией split brain в кластере. Это позволяет удешевить решение для филиала, использовав для инфраструктуры из 25 машин всего 2 сервера. Более подробно о ROBO-сценарии написано вот тут.
А вот как выглядит настройка ROBO-издания Virtual SAN:
Ну и, само собой, ROBO-сценарии можно реализовывать по своему усмотрению на лицензиях Standard или Advanced.
Мы уже немало писали про технологию использования хранилищ VVols (например, здесь и здесь), которая позволяет существенно увеличить производительность операций по работе с хранилищами в среде VMware vSphere за счет использования отдельных логических томов под компоненты виртуальных машин и передачи части операций по работе с ними на сторону дисковых массивов.
Давайте посмотрим, как же технология VVols влияет на процесс резервного копирования виртуальных машин, например, с помощью основного продукта для бэкапа ВМ Veeam Backup and Replication, который полностью поддерживает VVols. Для начала рассмотрим основные способы резервного копирования, которые есть в виртуальной среде:
Резервное копирование за счет монтирования виртуальных дисков (Hot Add backup) - в этом случае к одной ВМ монтируется диск VMDK другой ВМ и происходит его резервное копирование
Резервное копирование по сети передачи данных (NBD backup) - это обычное резервное копирование ВМ по сети Ethernet, когда снимается снапшот ВМ (команды отдаются хостом ESXi), основной диск передается на бэкап таргет, а потом снапшот применяется к основному диску ("склеивается" с ним) и машина продолжает работать как раньше.
Резервное копирование по сети SAN (SAN-to-SAN backup) - в этом случае на выделенном сервере (Backup Server) через специальный механизм Virtual Disk API происходит снятие снапшота ВМ без задействования хоста ESXi и бэкап машины на целевое хранилище напрямую в сети SAN без задействования среды Ethernet.
Последний способ - самый быстрый и эффективный, но он требует наличия специальных интерфейсов (vSphere APIs и Virtual Disk Development Kit, VDDK), которые должны присутствовать на выделенном сервере.
К сожалению, для VVols способ резервного копирования по сети SAN еще не поддерживается, так как данный механизм для прямой работы с хранилищами SAN для VVols еще не разработан. Поэтому при работе с VVols придется использовать NBD backup. Однако не расстраивайтесь - большинство компаний именно его и используют для резервного копирования машин на томах VMFS в силу различных причин.
Работа хоста VMware ESXi с томами виртуальной машины VVols выглядит следующим образом:
Для процессинга операций используется Protocol Endpoint (PE), который представляет собой специальный административный LUN на хранилище. PE работает с лунами машин (VVols), которые представлены через secondary LUN ID, а VASA Provider со стороны дискового массива снабжает vCenter информацией о саблунах виртуальных машин, чтобы хост ESXi мог с ними работать через PE.
Таким образом, в новой архитектуре VVols пока не прикрутили технологический процесс соединения стороннего сервера с VVols виртуальных машин и снятия с них резервных копий.
Вернемся к процессу резервного копирования. Как известно, он опирается на механизм работы снапшотов (Snapshots) - перед снятием резервной копии у ВМ делается снапшот, который позволяет перевести базовый диск в Read Only, а изменения писать в дельта-диск снапшота. Далее базовый диск ВМ копируется бэкап-сервером, ну а после того, как базовый диск скопирован, снапшот склеивается с основным диском, возвращая диски машины обратно в консолидированное состояние.
Так это работает для файловой системы VMFS, которая развертывается поверх LUN дискового массива. Сами понимаете, что при интенсивной нагрузке во время резервного копирования (особенно больших виртуальных дисков) с момента снятия снапшота может пройти довольно много времени. Поэтому в дельта-дисках может накопиться много данных, и процесс консолидации снапшота на практике иногда занимает часы!
Для виртуальных томов VVols все работает несколько иначе. Давайте взглянем на видео:
В среде VVols при снятии снапшота базовый диск остается режиме Read/Write (это все делает массив), то есть контекст записи данных никуда не переключается, и изменения пишутся в базовый диск. В снапшоты (это отдельные тома VVol) пишется только информация об изменениях базового диска (какие дисковые блоки были изменены с момента снятия снапшота).
Ну а при удалении снапшота по окончанию резервного копирования никакой консолидации с базовым диском производить не требуется - так как мы продолжаем с ним работать, просто отбрасывая дельта-диски.
Такой рабочий процесс несколько увеличивает время создания снапшота в среде VVols:
Но это всего лишь десятки секунд разницы. А вот время консолидации снапшота по окончанию резервного копирования уменьшается во много раз:
Как следствие, мы имеем уменьшение совокупного времени резервного копирования до 30%:
Так что, если говорить с точки зрения резервного копирования виртуальных машин, переход на VVols обязательно даст вам прирост производительности операций резервного копирования и позволит уменьшить ваше окно РК.
Известный блоггер Vladan Seget написал интересную статью (и даже не одну, а несколько) о различных способах развертывания средства StarWind Virtual SAN, предназначенного для создания отказоустойчивого кластера хранилищ под виртуальные машины.
Вот 3 основных метода развертывания StarWind Virtual SAN:
Обычная установка на Windows-систему. Сделать это можно в пробном режиме бесплатно, или имея соответствующую лицензию на продукт.
Более подробно об этом методе развертывания StarWind Virtual SAN написано вот тут.
Установка на бесплатный Microsoft Hyper-V Server. Этот метод не требует вообще никаких вложений, даже в лицензию на Windows Server, так как Hyper-V Server бесплатен. Но вам потребуется Windows-машина (не обязательно сервер) для установки консоли StarWind, так как в Hyper-V Server нет оконного интерфейса.
Об этом методе установки StarWind Virtual SAN написано здесь.
Установка из виртуального модуля OVF. Этот способ и описан в последней статье Владана. Такой способ установки позволяет загрузить уже готовую виртуальную машину StarWind Virtual SAN для Microsoft Hyper-V (ее можно преобразовать в формат VMware VMDK из VHDX с помощью бесплатного StarWind V2V Converter).
Все делается достаточно просто, и весь процесс занимает не более часа. Попробуйте!
RSS
